It is desirable, in a variety of contexts, to capture signals. The nature of the signals may vary from context to context. For example, in a medical context, it may be desirable to capture signals that represent heart activity. In the context of sound studios, it may be desirable to capture audio signals produced by music artists. The techniques described herein are not limited to any particular type of recorded signal. The digital representation of a signal is referred to herein as “signal data”.
For a variety of reasons, it may be desirable to edit the signal data after a signal has been digitally recorded. For example, an audio recording of a lecture may include a cough that should be removed. In addition to problems created by the recording environment (such as a coughing audience), the recording process itself may introduce problems, such as hissing or popping noises, that should be removed from the recording.
Many signal editing applications are available for performing post-recording edits to a captured signal. In the context of audio signals, many audio editing applications allow a user to listen to the audio. While the audio is being played, the user is presented with a visual representation of the signal, with an indication of the location, within the signal, that is currently being played. While listening to the audio and watching the visual representation of the signal, the user may identify a problem that requires fixing. For example, the user may hear a “cough”, and see a spike that represents the cough in the visual representation of the signal. The user may then use a tool provided by the editing application to correct the problem. For example, the user may replace the portion of the signal that contains the cough with an ambient noise print, as described in U.S. patent application Ser. No. 11/104,995, filed on Apr. 12, 2005, the contents of which are incorporated herein by this reference.
Some sophisticated signal editing applications may even provide error correction tools that do not require the user to identify the location of the problem. For example, a sound editing application may simply have a “remove pops” option. When selected, the “remove pops” tool attempts to find and remove all “pops” in the recorded signal. While such tools relieve the user of the responsibility of finding the “pops”, they do so by reducing the user's control over the editing process. For example, the “remove pops” tool may remove some sounds that the user wants to keep in the signal, and may leave in some sounds that should be removed. No matter how accurate the tool is, it cannot be guaranteed to perform all of the edits the user desires, and only those edits that the user desires.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.